Problem

spp_oauth granted base.group_user (every internal user) read + write on
res.config.settings, which exposes oauth_priv_key — the RS256 JWT signing key used
by calculate_signature() — and oauth_pub_key. A low-privileged internal user could:

• Read the private key and forge OAuth/JWT tokens that verify_and_decode_signature()
  accepts (full API auth bypass / impersonation), and
• Overwrite the keypair to break or subvert authentication (tamper / DoS).

Severity: High/Critical — this is a signing credential, not a config toggle.

Why the ACL fix alone is not enough

res.config.settings.default_get() (Odoo core base/models/res_config.py) reads
config_parameter fields via ir.config_parameter.sudo() and performs no model-ACL or
field-group check. It is an @api.model method reachable over RPC, so
env['res.config.settings'].default_get(['oauth_priv_key']) leaks the key regardless of the
ACL. This was reproduced by a failing test before the fix (the plain-user default_get
result contained the private key). Both changes below are required.

Changes

1. Remove the over-broad ir.model.access row. Odoo core already grants
   res.config.settings to base.group_system (read/write/create), so system admins keep
   full access and can still Save settings. This was the only module in the repo widening this
   model to base.group_user.
2. Override default_get to strip oauth_priv_key/oauth_pub_key for users who are not
   base.group_system, closing the sudo RPC path. (A groups= field attribute would not fix
   this — field groups are not enforced in default_get's config loop.)
3. Bump manifest 19.0.2.0.0 → 19.0.2.0.1.

Tests

New spp_oauth/tests/test_config_settings_acl.py:

• plain internal user is denied model access to res.config.settings (AccessError);
• plain internal user cannot read the keys via default_get;
• system admin retains model access and can read both keys via default_get.

Written test-first (failing → passing). ./spp test spp_oauth → 14 passed, 0 failed;
./spp lint clean.

⚠️ Operational remediation required

Every internal user has had read access to the signing key historically, so the deployed
RSA keypair must be treated as compromised. After upgrading, operators should rotate
(regenerate) the keypair and invalidate any outstanding tokens. A code fix cannot un-leak an
already-exposed key.

Out of scope (noted for awareness)

• Placeholder values in data/ir_config_parameter_data.xml (YourPrivateKeyHere /
  YourPublicKeyHere) are non-secret placeholders.
• Empty 0-byte spp_oauth/tools/private_key.pem / public_key.pub are unused (keys are read
  only from ir.config_parameter).
• password="true" on the settings view fields is display masking only, not an access control.